NEXUS-Q Vault
Desktop encryption for individual files and folders, with encrypted vault backups. v0.1.0 · Early access.
/ open source / live repository
Project activity, from GitHub.
Live public repository metadata. Counts are supplied by GitHub and may be temporarily unavailable due to API limits.
—Stars
—Forks
—Open issues & PRs
—Last push
—Latest release
—Contributors
Loading public GitHub data…
/ ecosystem / applications
Explore NEXUS-Q apps.
Choose the desktop vault or the collection of 25 command-line tools.
NEXUS-Q Tools · 25 CLI tools
Independent Rust commands for diagnostics, files, manifests, integrity, signatures, backups and developer workflows.
/ latest release · 2026-10-22
v4.1.2 release: what changed
The GitHub release NEXUS-Q v4.1.2 consolidates the 4.1.2 development cycle across the Rust core, PKI, signing, SDKs and native runtime distribution. It is a published release—not a claim of independent certification or production readiness.
Post-quantum PKI
PQC X.509 certificate issuance, OCSP responses and CRL publication, plus ACME, EST and CMPv2 enrollment workflows.
Signing and timestamping
PKCS#11-based ML-DSA signing integration, M-of-N signing ceremonies and RFC 3161 timestamp tokens using ML-DSA.
Availability and administration
Tenant-scoped CA/OCSP replication and recovery, role-based access control, encrypted backups and audit logging.
SDKs and runtime
Consolidated Rust/C, Python, .NET, TypeScript, Java/Kotlin, Swift, Go, Ruby, PHP and Dart integration, with version-matched runtime assets and SHA-256 checks where supported.
v4.1.2 release evidence
The tag-gated workflow completed successfully on commit 8735e553: the release gate, cross-platform builds, SDK smoke, reproducible packaging, runtime artifacts, provenance, checksums, artifact attestation and GitHub release publication passed. Automated checks cover tested configurations; they do not prove that vulnerabilities are absent.
v4.1.2 release workflow · Rust 1.88 MSRV CI · Published release
Historical v4.1.1 provenance caveat
The historical v4.1.1 tag moved to current main, but nexusq-v4.1.1-provenance.json and the previously published release assets still identify commit 5dd564d. Do not assume the mutable tag and those historical assets describe the same source snapshot.
Review historical release assets · Full project status in README
Security status: no independent external audit, FIPS 140-3 validation, formal verification or blanket production-readiness claim is made. The native ML-KEM/ML-DSA backend remains experimental and opt-in; RustCrypto remains the default for normal production call paths. Release notes · Native runtime packaging.
/ overview
What is NEXUS-Q?
A post-quantum cryptographic security engine. It is a library first: a Rust core that does all the cryptography, with a command line, an HTTP server and language SDKs layered on top. It is meant to be embedded in applications and servers that need to protect secrets for the long term.
Data
Authenticated encryption of files and streams, with envelope encryption (format F-02) so payloads are protected under a key that is itself protected.
Keys
The full key lifecycle: generation, rotation, revocation and destruction, stored in an encrypted vault (format F-01) with atomic writes.
Identities
Digital signatures, signature verification, identity rotation and revocation, and signed verifiable credentials.
Why post-quantum?
Large quantum computers would break the public-key schemes in wide use today (RSA, elliptic curves), and data recorded now could be decrypted later. NEXUS-Q uses the NIST-standardized lattice algorithms ML-KEM and ML-DSA, and pairs the key exchange with classical X25519 as a hybrid.
The golden rule
We do not invent cryptography. Every primitive is a standardized algorithm implemented by a maintained library. Deviations need a written architecture decision record. The project also states plainly that it does not claim every dependency has been independently audited.
/ how it works
From password to protected data
Every operation goes through the same building blocks. Policy decides who may act, the vault guards the keys, and security-relevant events are written to an audit log that detects tampering.
01
Unlock the vault
A password goes through Argon2id to unlock the encrypted vault. The vault holds keys at rest and is written atomically.
02
Manage keys
Generate, rotate, revoke and destroy keys. Secrets are zeroized in memory when they are no longer needed.
03
Encrypt or sign
Hybrid ML-KEM + X25519 for key exchange, AES-256-GCM or ChaCha20-Poly1305 for data, Ed25519, ML-DSA-65 or SLH-DSA for signatures.
04
Enforce policy
A deny-by-default policy engine decides which actions are allowed before they happen.
05
Audit everything
An HMAC-authenticated audit log with rollback anchoring makes tampering and truncation detectable.
Library first
The core is a Rust library. The CLI, the server and the SDKs are thin layers on top and contain no cryptography of their own.
Hardware-agnostic boundary
Provider traits exist for software, TPM, HSM, Secure Element and RISC-V. Hardware isolation is only claimed when a provider is implemented and tested. The default software backend does not provide it.
Security from the ground up
The threat model and the cryptographic rules were written before the code, and they are part of the repository.
/ architecture
What is in the repository
A Rust workspace with the core library, CLI, authenticated server, multi-language SDKs, an opt-in experimental native backend, and a reproducible benchmark arena.
| Component | What it is |
|---|---|
| nexusq-core | The library. All cryptography, vault, key management, identity, policy, storage and hardware abstraction live here. |
| nexusq-cli | The nexusq binary: vault, key, data, sign, identity, credential and audit commands. A thin wrapper over the library. |
| nexusq-server | The nexusq-server binary and authenticated HTTP service, with health, readiness and Prometheus-style metrics endpoints. |
| nexusq-c · nexusq-py | The C ABI and Python extension, built on the core library; the Python 4.1.2 registry upload is source distribution only. |
| Optional Rust services | nexusq-admin, nexusq-enrollment, nexusq-ha, nexusq-hsm, nexusq-ocsp, nexusq-pki-cluster, nexusq-tsa, nexusq-x509 — administration, enrollment, HA/recovery, HSM and PKI modules. These auxiliary crates remain available at their published v4.1.1 versions; the v4.1.2 documentation closeout did not republish them. Consult module docs for their operational boundaries. |
| Language SDKs | TypeScript/Node.js, Java, Kotlin, .NET, Swift, Dart, Go, PHP and Ruby. Many are thin FFI bindings over libnexusq; package status, platform support and native runtime requirements differ by ecosystem. |
| bindings/go · php · ruby | Language bindings covered by a dedicated SDK CI workflow. |
| arena/ | The PQC Benchmark Arena: pinned external implementations, a normalized JSONL protocol and retained CI artifacts. |
| fuzz/ · artifact-archive/ | Fuzz targets, and the archived V1/V2/V3 evidence with SHA-256 manifests. |
Targets
Linux x86_64 and aarch64, Android/Termux aarch64, and RISC-V (riscv64gc) with a verified build.
Requirements
Building current main requires Rust 1.88 or newer (edition 2024) and Git. Published packages can have different source provenance and toolchain requirements; check the specific package before targeting an older compiler. SDK toolchains are only needed for the binding you build.
Storage
Encrypted vault, envelope format, backup bundles and a storage database, all with documented formats.
Observability
Request IDs, aggregate metrics, health and readiness probes. Secrets are kept out of logs.
/ packages & distribution
Install NEXUS-Q from package registries
Version 4.1.2 is published across Rust, Python, JavaScript, Java, Kotlin, .NET, Dart, PHP and Ruby channels, with a separate Go module version and a Swift tag caveat. Registry availability is not proof that every artifact was built from the same Git commit, nor does publication imply an independent audit, certification or production readiness. Most FFI SDKs require the NEXUS-Q C library (libnexusq) to be installed on the system first.
RustCore crates · CLI · server · PKI
Open a crate directly on crates.io or expand this card to browse the Rust packages in the 4.1.2 family.
nexusqcrates.io ↗nexusq-corecrates.io ↗nexusq-kernelscrates.io ↗nexusq-ml-kemcrates.io ↗nexusq-ml-dsacrates.io ↗nexusq-clicrates.io ↗nexusq-servercrates.io ↗nexusq-ccrates.io ↗nexusq-admincrates.io ↗nexusq-pki-clustercrates.io ↗nexusq-hsmcrates.io ↗nexusq-enrollmentcrates.io ↗nexusq-hacrates.io ↗nexusq-ocspcrates.io ↗nexusq-tsacrates.io ↗nexusq-x509crates.io ↗nexusq-pycrates.io ↗nexusq-native-backendcrates.io ↗Experimental: nexusq-native-backend 0.1.0 is opt-in only.
C / C++Native FFI library
nexusq-c 4.1.2 · C ABI used by many of the language bindings.
PythonPyPI · source distribution
nexusq==4.1.2 · currently published as a source distribution only; no wheel is listed.
pip install nexusq==4.1.2
TypeScript / Node.jsnpm · koffi binding
JavaMaven Central · JNA
io.github.lecodev-26:nexusq:4.1.2
implementation("io.github.lecodev-26:nexusq:4.1.2")
KotlinMaven Central · JNA
io.github.lecodev-26:nexusq-kotlin:4.1.2
implementation("io.github.lecodev-26:nexusq-kotlin:4.1.2")
C# / .NETNuGet · .NET 9
Nexusq 4.1.2 · includes native runtime assets.
dotnet add package Nexusq --version 4.1.2
SwiftSwiftPM · v4.1.2
Current SwiftPM release: use the repository with version requirement from: "4.1.2", resolved from the published v4.1.2 tag. The v4.1.1 tag/provenance issue is historical.
Dart / Flutterpub.dev · dart:ffi
Gopkg.go.dev · v0.1.0
Go binding has its own versioning (v0.1.0).
go get github.com/lecodev-26/nexus-q/bindings/go/nexusq@v0.1.0
PHPPackagist · FFI
RubyRubyGems · FFI
Most FFI SDKs need the NEXUS-Q C library (libnexusq) installed locally first. Registry availability does not prove every artifact came from the same Git commit. The Python 4.1.2 upload is source-only; Go uses independent module version v0.1.0 and its native runtime is pinned to verified 4.1.2. Read the installation matrix and runtime packaging guide for details.
Native runtime selection and platform support differ by SDK; many language bindings are thin FFI wrappers over libnexusq. The Python 4.1.2 upload is source-only; Go uses independent module version v0.1.0 and its native runtime is pinned to verified 4.1.2. Check the repository installation matrix and runtime packaging guide for exact requirements.
/ cryptography
Six families, nothing else
The core is only allowed to use six families of primitives. Anything outside them, such as raw RSA or custom MACs, is forbidden by the project's own rules.
| Family | Purpose | Implemented |
|---|---|---|
| Randomness | Entropy for keys, nonces and salts | OS CSPRNG, plus TRNG support with health checks and mixing |
| Hashing | Digests and commitments | SHA-2, SHA-3 |
| KDF | Passwords and key material to keys | Argon2id, HKDF |
| AEAD | Symmetric authenticated encryption | AES-256-GCM, ChaCha20-Poly1305 |
| KEM | Post-quantum key encapsulation | ML-KEM-768 and ML-KEM-1024, hybrid with X25519 |
| Signatures | Authenticity and non-repudiation | Ed25519, ML-DSA-65, SLH-DSA-SHAKE-128f |
Planned algorithms are never described as available until they are implemented and tested. The reference document is docs/CRYPTOGRAPHY.md.
/ benchmarks
v4.1.0 official production-path benchmark
The official 2026-10-19 run records 241 normalized PQC Benchmark Arena measurements. The opt-in native backend passed the unchanged 1.5× median-and-p95 gate against AWS-LC on all nine ML-KEM and ML-DSA production-path operations. Lower latency is better; these are measurements from one AMD EPYC 7763 hosted CI runner, not universal performance claims.
NEXUS-Q nativeAWS-LCMedian latency · shorter is faster
ML-KEM-768 · Keygen
ML-KEM-768 · Encaps
ML-KEM-768 · Decaps
ML-KEM-1024 · Keygen
ML-KEM-1024 · Encaps
ML-KEM-1024 · Decaps
ML-DSA-65 · Keygen
ML-DSA-65 · Sign
ML-DSA-65 · Verify
0255075100 µs
Visual comparison of the recorded median latency. Exact median/p95 values and methodology remain available in BENCHMARKS.md.
Issue #23 — local final-gate diagnostic (Oct 21, 2026)
Separate from the official v4.1.0 hosted AMD EPYC benchmark above. On an Intel Core i3-N305 Linux host in powersave mode, the owner-accepted local matched-RNG comparison beat or matched the best eligible comparator on median and p95 for 6 of 9 operations. Three residual gaps remain accepted: ML-DSA-65 signing (1.063× median / 1.115× p95), ML-KEM-1024 keygen (1.021× / 1.020×) and ML-KEM-768 keygen (1.015× / 1.013×). These local results are not hosted CI evidence and do not replace the official 1.5× gate.
Important scope note. The native backend is experimental and opt-in only. The default
nexusq-core build, CLI, server and SDK production call paths continue to use RustCrypto. The 1.5× gate is a performance gate, not a security audit or certification. Independent external audit remains pending. Official Arena run (241 measurements) · Production-path gate · Feature and scope documentation./ versions & roadmap
Current stable line and engineering history
V1, V2 and V3 remain historical engineering baselines. v4.1.2 is the latest published GitHub release; v4.1.0 retains the official benchmark record described above. The historical v4.1.1 tag and its existing assets have a documented provenance mismatch. The current v4.1.2 release does not imply an independent audit, certification or production readiness.
v1.0.0 · Oct 7, 2026
V1
The frozen engineering baseline: crypto core, vault, keys, identities, policy, audit log, CLI, server and SDKs. Its Arena result showed NEXUS-Q slower than the fastest implementations, which became the main target.
Frozenv2.0.0 · Oct 8, 2026
V2
Correctness, interoperability, security fuzzing, backend strategy and release gates. The final record claims no performance improvement over V1, and the performance question stayed open.
Frozen on nexusqv2Oct 9, 2026 · PR #45
V3
Hardened implementation, reproducible Arena, corrected benchmark sampling and retained evidence archive with SHA-256 manifest.
Engineering releaseOct 19, 2026 · v4.1.0
V4.1
Previous stable line and source of the published 241-measurement Arena record. The native backend passed the 1.5× median-and-p95 gates in the recorded configuration but remains explicitly opt-in.
Previous stable lineOct 27, 2026 · v4.1.2
V4.1.2
Release designation consolidating PKI certificate issuance, OCSP/CRL, ACME/EST/CMPv2 enrollment, PKCS#11 ML-DSA signing, RFC 3161 timestamping, HA/recovery, administrative controls and multi-language SDK/runtime work.
Latest published release · audit not claimed/ security posture
What we claim, and what we do not
Cryptographic software earns trust slowly. This is the project's own statement of its current assurance level.
Claimed and evidenced
- Standardized algorithms only, through maintained libraries
- Secrets zeroized when no longer needed
- Tamper-evident, HMAC-authenticated audit log
- Deny-by-default policy engine
- Security CI gates, SDK CI, benchmark CI and fuzz targets
- Published threat model and security model
- Dual license: MIT or Apache-2.0
Not claimed
- Independent external security audit
- FIPS validation or Common Criteria certification
- Formal verification
- Production readiness
- Security endorsement, audit, or production readiness implied by publication to a package registry
- Hardware isolation from the default software backend
- Performance leadership
Found a vulnerability? Report it privately through GitHub Security Advisories, not a public issue. See SECURITY.md.
/ quick start
Build it and use it
To build current main, use Rust 1.88 or newer. Linux and Android/Termux are the environments exercised most; published packages may have different toolchain requirements.
1 · Build
# clone and build the workspace
git clone https://github.com/lecodev-26/nexus-q
cd nexus-q
cargo build --workspace --release2 · Create a vault
./target/release/nexusq vault create ./example.nqv ./target/release/nexusq vault status ./example.nqv ./target/release/nexusq health
3 · Generate a key
./target/release/nexusq key generate ./example.nqv \ --algorithm ed25519 --purpose sign \ --password-file ./password.txt ./target/release/nexusq key list ./example.nqv
4 · Encrypt and decrypt data
./target/release/nexusq data encrypt ./example.nqv \ --key-id <key-id> ./secret.txt ./target/release/nexusq data decrypt ./example.nqv \ ./secret.txt.nqx ./secret.out
Prefer --password-file over typing a password on the command line, and never commit that file. The full command list is in the CLI guide. Server setup is in docs/SERVER.md.
/ contribute
How you can help
NEXUS-Q is built in the open and is still young. The most useful help right now is scrutiny: more eyes, more hardware and more honest measurements. Some of these need no cryptography background.
Run the Arena on your hardware
Reproduce the benchmark numbers on your own CPU and share what you find in an issue. Differences between machines affect reproducibility; treat local results as observations, not official gate evidence. Start with arena/README.md.
Review the threat model
Read the threat model and the security model, and tell us what is missing or wrong. A gap in the reasoning is worth more than praise.
Test on your platform
Build the workspace and run the tests on Linux, Android/Termux or RISC-V, and report anything that fails or behaves differently.
V4 engineering status
The native ML-KEM/ML-DSA backend is experimental and opt-in. Normal production call paths in the core, CLI, server and SDKs default to RustCrypto. The v4.1.2 release does not claim an independent external audit, FIPS 140-3 validation, formal verification or blanket production readiness.
Found a vulnerability? Please report it privately through GitHub Security Advisories, not in a public issue. See SECURITY.md.
/ documentation
Where to read next
The repository has task guides, API and deployment references, architecture decisions, CI documentation, security assessments and historical performance evidence. Start with a task guide or browse by topic. Implementation, package publication and operational readiness are separate statuses.
User guidestart here
Installationpackages and source build
Getting startedfirst steps
Troubleshootingdiagnose common problems
API referenceinterfaces and contracts
Cross-compilationbuild for other targets
Architecturesystem design
Threat modelwhat we defend against
Cryptographyalgorithms and rules
Key managementlifecycle
Security modelguarantees
Storagepersistent formats
Policyaccess control
SDK guidebinding overview
TypeScript SDKNode.js / koffi
Java SDKJNA binding
Kotlin SDKJNA binding
.NET SDKP/Invoke + native assets
Swift SDKSwiftPM system library
Dart SDKdart:ffi
Go SDKseparate v0.1.0 version
PHP SDKFFI runtime
Ruby SDKFFI runtime
Deploymentrunning the server
HTTP serverconfiguration and operations
Native runtime packagingABI and platform limits
Secure bootmeasured boot design
CI pipelineworkflow phases and gates
Architecture decisionsADRs 0001–0004
Security assessmentsissues #70–#71 and follow-ups
Commercial readinessdeployment and release gaps
Project roadmapphases and priorities
Benchmarksraw numbers and methodology
Issue #23 final auditlocal results and residual gaps
Release notesscope and release caveats
V3 and V4 statusversion history and current boundaries
/ developers / learn and integrate
Build with post-quantum cryptography.
NEXUS-Q is an independent open-source Rust cryptographic engine with ML-KEM, ML-DSA and language integrations. It is not affiliated with Google and is unrelated to the discontinued Google Nexus Q media player.
Learn about PQC
Understand post-quantum cryptography, ML-KEM, ML-DSA and the NIST standards.
Post-quantum cryptography guide ↗Choose your SDK
Explore Rust, Python, TypeScript, Java, Kotlin, .NET and other language bindings with their actual requirements.
PQC SDK catalogue ↗Install NEXUS-Q
Follow the Rust or Python quick start and check native runtime requirements.
Installation guide ↗Build with Rust or Python
Read language-specific setup notes and package information.
Rust guide ↗ · Python guide ↗/ faq
Questions people ask
Is NEXUS-Q ready for production?
The project does not claim production readiness. It is an engineering project with strong CI gates, but there has been no independent audit or certification. Evaluate it, review it, and treat it accordingly.
Has it been audited?
No independent external audit has been completed, and none is implied by a GitHub release. The project states it will link a public evidence package from the repository if one exists.
How does NEXUS-Q perform compared with AWS-LC?
Performance depends on the backend and operation, so a blanket claim that NEXUS-Q is slower would be misleading. The default build uses RustCrypto; the opt-in native backend passed the reviewed CI gate of at most 1.5× AWS-LC latency for both median and p95 across all nine measured ML-KEM and ML-DSA operations. That gate allows some operations to be slower; it does not claim the native backend is faster in every case, and primitive benchmarks are not end-to-end application benchmarks.
Why combine ML-KEM with X25519?
A hybrid keeps the key exchange protected as long as at least one of the two schemes holds up. That is the usual reasoning for hybrids while post-quantum algorithms are still young in deployment.
Can I use it from Python, Go, C, PHP or Ruby?
Yes. Python is published on PyPI; Go is available via pkg.go.dev; PHP on Packagist; and Ruby on RubyGems. The C SDK is published on crates.io. The FFI wrappers require the C library (libnexusq) to be installed locally first. See the package table and SDK guide.
What license is it under?
You can choose either the MIT license or the Apache License 2.0, the same dual license used by much of the Rust ecosystem.
How can I help?
Read the threat model, run the Arena yourself, review the code, and open an issue or a pull request. v4.1.2 is the latest GitHub release; independent external audit remains open. The known tag/assets provenance mismatch is a historical v4.1.1 issue. Security reports go through GitHub Security Advisories.